Networks interconnect hosts using a variety of network devices, including host network adapters, routers, switches and hubs, each of which include network interfaces for interconnecting the various devices via cables and fibers. Applications send data over a network by submitting it to an operating system, after which it becomes network traffic. Network devices generally use a combination of hardware and software to forward network traffic from one network interface to another. Each interface can send and receive network traffic at a finite rate, and if the rate at which traffic is directed to a network interface exceeds the rate at which the network interface can forward the traffic onward, congestion occurs. Network devices may handle this condition by queuing traffic in the device's memory until the congestion subsides. In other cases, network equipment may discard some excess traffic to alleviate congestion.
As a result, applications sending network data experience varying latency or traffic loss. Applications generate traffic at varying rates and generally require that the network be able to carry traffic at the rate at which they generate it. In addition, applications differ in how tolerant they are of traffic delays in the network, and of variation in traffic delay. For example, certain applications can tolerate some degree of traffic loss, while others cannot. As a result, different applications have different requirements regarding the handling of their traffic in the network.
Network Quality of Service (QoS) refers to the ability of the network to handle network traffic such that it meets the service needs of certain applications. To this end, network QoS requires fundamental traffic handling mechanisms in the network, the ability to identify traffic that is entitled to these mechanisms and the ability to control these mechanisms. The fundamental traffic handling mechanisms that comprise a QoS-enabled network include the capacity of interfaces to forward traffic, the memory available to store traffic in network devices, (until it can be forwarded), and mechanisms internal to network devices that determine which traffic gets preferential access to these resources.
Because network resources are finite, there are parts of the network wherein resources are unable to meet demand. QoS mechanisms work by controlling the allocation of network resources to application traffic in a manner that meets the application's service requirements. Devices that provide QoS support do so by intelligently allocating resources to submitted traffic. For example, under congestion, a network device might choose to queue traffic of applications that are more latency tolerant (or did not specify their latency tolerance to the network) instead of traffic of applications that are less latency tolerant. As a result, the traffic of applications that are less latency tolerant can be forwarded immediately to the next network device. In this example, interface capacity is a resource which is granted to the latency-intolerant traffic, while device memory is a resource that has been granted to the latency-tolerant traffic.
In order to allot resources preferentially to certain traffic, it is necessary to identify different traffic and to associate it with the resources it requires. This is accomplished by recognizing separate traffic flows within the network and by defining traffic handling parameters which apply to these flows. Devices identify packets as belonging to one flow or another. In order to invoke QoS mechanisms, it is necessary to communicate to network devices the information necessary to associate packets with flows, and a description of the handling that should apply to traffic on each flow. This is achieved through various signaling means and device configuration.
While the benefits of QoS are generally acknowledged, the benefits with respect to latency have not heretofore been quantified. Indeed, although general attempts have been made to attempt to measure how QoS actually helps transmission of data over a network, existing tools are inadequate for quantifying the benefit of QoS. For example, one such tool reports results at a very coarse level, by sending an amount of data and determining how long it took to receive that data. As a result, relatively little information is obtained with this technique, and indeed, other factors such as non-network related delays are factored into the transmission time. Other tools such as “Ping” provide more information, but do so at relatively low resolution, (e.g., ten millisecond bins are provided, whereby packets less than this amount are placed into the less-than-ten millisecond bin regardless of how fast they were actually transmitted), and/or merely provide average latency information.
Further, there are also methods for calculating Round Trip Time (RTT) estimates. RTT helps transport level protocols in estimating the congestion in the network, but because the congestion is measured, the technique is limited to round trip measurements even though the latency estimate is not the same in both directions. However, network QoS provides benefits in solving latency problems in just one direction as well as in both. As a result, measurement of latency in one direction is an important part of proving the benefits of QoS, but has heretofore been unavailable.
Still other tools are complex, relying on devices such as radios, satellite receivers or modems to attempt to synchronize the clocks at the sender and receiver so that send and receive times are in synchronization whereby the actual latency can be measured to an extent. For example, Network Time Protocol (NTP) is one such method for synchronizing clocks on computers, but has drawbacks in that it requires the machines to communicate with an NTP server either via a radio, satellite receiver or modem. Regardless of the device used, the resulting synchronization is only approximate because synchronizing the clocks on any two machines is virtually impossible. At present, a modem connection to the NTP server provides synchronization within a range on the order of a few tens of milliseconds, while radio and satellite receiver connections may be synchronized to within approximately a millisecond range. Although such ranges may provide better resolution than other existing methods, the abovementioned devices are not easily accessible, and moreover, the modem case is too loosely bounded for use in accurate measurements of latency.